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Abstract. SelectScript is an extendable, adaptable, and declarative domain- 
specific language aimed at information retrieval from simulation environments 
and robotic world models in an SQL-like manner. In this work we have ex¬ 
tended the language in two directions. First, we have implemented hierarchical 
queries; second, we improve efficiency enabling manual design space explo¬ 
ration on different “search” strategies. As depicted in the teaser above, we 
demonstrate the applicability of such extensions in two application problems; 
the basic language concepts are explained by solving the classical problem of 
the Towers of Hanoi and then a common path planning problem in a complex 
3D environment is implemented. 


1. Introduction 

We have developed SelectScript [T] as a consequence to the growing com¬ 
plexity of (robotic) world models and discrete simulation environments that we are 
confronted with in our everyday scientific life. If we look at the world of robot¬ 
ics, smart environments, or cyber-physical systems, all of the entities within such 
newly developing ecologic systems posses their own simulation of the environment. 
Each of them with a very specific structures and APIs and different semantics. An 
intermediate language that can be put on top of all these world models with a com¬ 
mon semantic, would enable a “real” interoperability between these systems (not 
in the sense of sharing data, data sheets, or services). An entity could access the 
required information from another entities “head”, by defining what information 
it requires and in what representation format. SelectScript therefore adopts 
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the well known SQL syntax for discrete simulations, allowing to query them online 
and to manually explore the capabilities of the API together with the underlying 
environment. Within the following, we will use the terms simulation and world 
models synonymously, since a world model can be interpreted as a simulation of 
certain aspects of the world, further more we are demonstrating the capabilities of 
our query language by applying different simulation environments. 

SelectScript is a declarative domain-specific language (DSL) currently em¬ 
bedded in Python, further language implementations are planned. It is called 
SelectScript because, in contrast to a complete SQL implementation, we only 
provide the possibility for accessing and querying data, which is based on SELECT- 
statements, the development and integration of additional functionality is left out 
to the host programming language, e. g. Python, C++, etc. Additionally, we added 
new language features that allow to query for application-specific response formats, 
e. g. maps, sound, projections, etc., integrate temporal aspects, and offer interfaces 
that enable to extend the language according to different requirements (cf. Sec.[^. 

In this work we extend the SelectScript DSL to enable hierarchical queries. 
This does not only allow to solve classical reasoning problems such as the Towers 
of Hanoi or the Four Color Map problem, but also path planning in a complex 3D 
environment, as indicated by the teaser figure. Seeking for an appropriate method 
to resolve such hierarchical queries by implementing different strategies, we shortly 
realized that is actually possible and even more valuable to integrate different ones. 
But this requires to implement mechanisms that allow to switch between different 
strategies and to tweak them. Strategies with their specific details of implemen¬ 
tation, memory management, etc. can thus be abstracted and hidden behind the 
language. The SelectScript DSL allows to define what information is required 
as well as what “search” strategy to apply. No one would normally apply an SQL- 
like syntax to solve common reasoning problems, whereby it actually provides a 
convenient way of expressing problems. 

The contributions of this paper are: 

• We extend the SelectScript DSL with hierarchical queries, which enable 
recursion within the language. 

• We enable manual design space exploration on different “search” strategies. 

• We demonstrate the language improvements by implementing the Towers 
of Hanoi application and we show that the same concepts can be used in 
complex 3D environments to solve a common path planning problem. 


Overview. The next section is used to give a brief overview on related approaches. 
It is followed by an introduction into the basic and original language concept of Se¬ 
lectScript. In Sec. 1^ we discuss why a search problem can, in general, be seen 
as a table containing all possible intermediate steps, such that it becomes appar¬ 
ent that a declarative approach provides a convenient way to identify the relevant 
“rows” and thus solutions. The same section then introduces hierarchical queries. 
As already mentioned, the Towers of Hanoi are used to demonstrate stepwise the 
new concepts behind this work in Sec. |5.1| and a path planning problem in a com¬ 
plex 3D environment is then solved in Sec. |5.2[ A short summary is presented and 
an outlook onto future directions provided. 
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2. Related Work 

This work is an extension of a previous work from the same authors, an inter¬ 
ested reader can find SelectScript]^ explained in [T]. In that work an example 
of the OPEN robotics automation virtual environment (OpenRAVE) [2] is pro¬ 
vided. Nonetheless, we briefly introduce the basics of the SelectScript language 
in Sec. [3l 

DSLs have been widely used in research and industry to improve expressiveness 
for a variety of application domains such as robotics, computational science, compu¬ 
tational finance, image processing, music, graphics, artificial intelligence main El. 
As an example, in [3] the user is able to represent his variational data assimilation 
application under a specifically designed formalism. The compiler automatically 
generates code improving user productivity. The functionalities provided allow a 
user to run simulations in a specific world model representation, namely a struc¬ 
tured mesh. A similar approach on unstructured meshes is introduced by [4] where a 
high-level specification is provided using a syntax close to the mathematics, i. e. the 
partial differential equations, the software is intended to solve. The SelectScript 
DSL differs from these examples in the fact that it targets a general interface to 
world models and simulations. 

Another class of DSL is given by languages that are performance-oriented. These 
languages are often called performance DSLs miais]. As an example [8] imple¬ 
ments an access-execute model where the user specifies a stencil computation for 
unstructured meshes; the DSL decides how to execute the computation taking 
into account manual and automatic performance optimisation techniques. Effec¬ 
tive manual design space exploration is also proposed by [6] where the authors 
provide a mechanism for manually exploring different schedule choices. As we shall 
see, SelectScript also proposes an effective manual design space exploration. 

The robotics community has been active on the creation of DSLs for robotics. 
A compelling example that shares some commonalities with our work is RSG-DSL 
[To], which is a DSL focusing on robot scene graphs (RSGs) world model represen¬ 
tations. The restriction of considering RSGs-only is overcome by SelectScript. 
Another example is the robot perception specification language (RPSL) [11] which 
focuses on task knowledge and the variety of sensors a robot has to deal with when 
implementing a robot perception architecture (RPA). MeshSQL [12] defines queries 
for mesh-based physics simulations. In contrast to our approach, the results of a 
simulation are stored within a database, according to time and space. MeshSQL is 
thus a real extension of SQL 1999 and specialized on mesh data only. This query 
language is intended to enable researchers to interactively explore simulation data, 
to identify new and interesting effects. MeshSQL therefore offers temporal, spatial, 
statistical, and similarity queries, which require different types of return values, i. e. 
simple values, surfaces and slices in different formats. Other approaches adopt the 
SQL syntax. Eor example the language integrated query (LINQ) [13] extends some 
of the .NET languages to apply SQL queries to relational databases as well as to 
arrays. This is similar to other approaches in the Java world, Java query language 
(JQL) [14], SQL for Java Objects (JoSQL) [15], etc., but with a reduced syntax. All 
these approaches are a close match with the actual SQL language and do not meet 
the requirements of simulations and robotic world models nor the requirements of 
hierarchical querying. 

^A simplified version of the grammar and the base implementation can be found at: 

https://gitlab.com/OvGU-ESS/SelectScript 
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3. Language Basigs 

We will use the interpreter for the open dynamics engine (ODE) [16] on the 
“chaotic” simulatiorj^ of Fig. [l] to demonstrate the SelegeSgript basics and to 
show that the interpreter can be used on top of multiple environments. All the 
presented examples within this paper as well as the language implementation can 
be downloaded via git^. 

Additionally, the commented slides with the complete code can be downloaded as 
an IPython notebook at: http://nbviewer.ipython.org/url/gitlab.com/OvGU-ESS/ 
SelectScript_demos/raw/master/DSLRob-15/presentation.ipynb 

Furthermore, there are multiple different screencasts available at our YouTube- 
channel at: http://www.youtube.com/ivsmagdeburg 

The example in Fig. [I] depicts a chaotic but configurable simulatiorj^ in ODE. 
Objects of different size, shape, color, mass, direction, and speed appear within a 
box. These particles fly around, bump against each other, and colliding objects can 
explode, giving birth to other “white particles”, or vanish. The more time passes 
by, the more objects will be present in the box. All of the object parameters and 
their place of appearance are random values. 

How would you analyse this? In a traditional way we would use the API of the 
simulation framework and a programming language with a lot of loops. Instead 
Fig. [2] shows how such analysis can be led using SelegtSgript interactively. A 
user has to attach the ODE space variable, which is the host of the entire simulation 
environment, to the interpreter to make it accessible under the new variable name 
"space”. The SelegtSgript interpreter for ODE checks the variable type, e.g. 
whether it is a list, a dictionary, or an ODE space, etc., and applies the appropriate 
methods. 

As further depicted in Fig. and in Fig. the "space" variable can then be 
accessed in the FROM, as if it would be an ordinary table. As further visible, the 
listed “columns” within the SELECT expression are actually function calls, which 
offer a convenient way to abstract the API. All functions, with the exception of 
some internals such as eval, help, print, or to, are implemented externally in 
the host programming language and can be applied everywhere within a script. 
Functions are linked to the SelegtSgript interpreter similarly as it was done for 
variables, see also Lis. on page[TQ| An additional element, that does not belong 
to the standard SQL syntax, is the keyword this, which is a pointer pointing 
to the currently evaluated element in the FROM expression. Since functions can 
have multiple input parameters, it allows to call them with the correctly placed 
parameter sets, see the function id in the figure above. If a function is called 
within the SELECT expression and if it has only one input parameter, the this 
pointer is automatically passed without the need to write it in brackets, as for the 
functions mass and velocity in Fig. Everywhere else within a script functions 
are identified by a function name with following brackets. As already mentioned 
and depicted in Fig. SelegtSgript is a language embedded in Python. The 
source code of a script is compiled at runtime into an intermediate representation 
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( a ) tsim — 10 


( b ) tsim — 100 



(c) tsim — 250 


Figure 1. Screenshots of the particle simulation at different time steps. 


and then evaluated. An interaction between Python and our query language is 
described in more detail in the application of Sec. |5.1| 

A SeleceScript script can contain multiple queries, as depicted for the listing 
in Fig.[^ and queries can be nested. Intermediate results can be stored persistently 
in variables, allowing to reuse results and to define more complex query scripts. 
Thereby the last statement of a script is defining the return value and can there¬ 
fore also be a composition of multiple results, as for example in line 7 of Lis. 
Additionally SelectScript has also support for temporal variables, which allows 
previous results to be cached over a certain period of time. 


^Demo: http://www.youtube.com/watch?v=FlXNchlJC9Y 
^Source: https://gitlab.com/OvGU-ESS/odeViz 
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Figure 2. Screenshot of interactive data exploration via ipython. 


1 # SelectScript-Example 

2 spheres = 

3 SELECT obj 

4 FROM space 

5 WHERE isSphere(this) 

6 AS list; 

7 maxMass = max( 

8 SELECT mass 

9 FROM spheres 

10 AS 1ist ) ; 



Figure 3. SelegtSgript example for identifying the heaviest 
sphere (left) and visualization with reduced opacity for comple¬ 
menting objects (right). 

Next to the basic SELECT ... FROM ... WHERE syntax it is also possible to use the 
common GROUP BY and ORDER BY, but it is also possible to request certain response 
format. As it is depicted in the previous examples, the keyword AS followed by 
value, list, or diet, allows a representation format to be chosen. It has to be 
noted that if a dictionary is requested the function names within the SELECT ex¬ 
pression are used to define dictionary IDs. But it is also possible to implement new 
methods, see therefore the example in Lis. The requested results (plane) are 
projection matrices that can be further parameterized. The resulting 2D-matrices 
for mass and velocity that are returned as elements of a list, are afterwards visu¬ 
alized as a heat map and a spectral map (using Python Matplotlit]^, see Fig. 

In [1] it was further demonstrated for OpenRAVE, that it is possible to request a 
result AS OccupancyGrid for external planners, AS Prolog to support reasoning 
tasks, or even AS SensorMap that depicts the current sensor coverage of an area. 


^http://matplotlib.org 
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Listing 1. SelectScript with a requested visual abstractions of 
the simulation. The additional parameters for the plane projection 
are: the plane itself (1st), the starting point (2nd), the width, 
the height, and the resolution (3rd), and an optional blur (4th) 
parameter. 

1 # Select 2 dimensional projections ... 

2 Mass = SELECT mass FROM space WHERE hasBody(this) 

3 AS planeC’XY’, [-5,-5], [100,100,0.1], 3); 

4 Velocity= SELECT 1inearVelocity(this, 2) FROM space 

5 WHERE hasBody(this) 

6 AS planeC’XYM [-5,-5], [100,100,0.1], 3); 

7 [Mass, Velocity]; # return values 



(a) masses (heat map) 


(b) z-velocities (spectral map) 


Figure 4. Two 2D projections showing the results of the script 
in Lis. for cumulated masses and velocities. 


4. DSL Extension 


4.1. Graph and Table Representation Equivalence. As depicted in Fig. 
most of the common search problems can be represented as either a graph/tree or 
as a table, containing all possible combinations and thus paths within the graph or 
tree. It is obvious that a graph-like structure consumes less memory than a table, 
whereby a graph needs to be traversed every time in order to find an appropriate 
solution. A table that contains all “paths” can be explored more efficient, whereby 
different caching or indexing strategies are applied in the background, and filters 
can be applied, e. g. by directly requesting the row with the last entry cc. 

Nevertheless, we only apply the database metaphor onto common search and 
reasoning problems. The “graph/tree” therefore still has to be created and tra¬ 
versed, but this is handled in the background. Applying an SQL-like syntax offers 
a more “natural” way to express problems and it furthermore offers a method to 
utilize different search algorithms and methods for optimization, without the need 
for changing the problem description. Note that the order of rows within the table 


in Fig. 5b is a result of an applied depth-first search algorithm. 
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(a) Connected undirected graph 
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(b) Table of poss. paths 


Figure 5. The Tower of Hanoi problem with two disks. Both 
representations can be used to identify a valid path and thus the 
intermediate to get from configuration aa to cc. The letters mark 
the positions of the disks (tower) and their order is used to mark 
their size (starting with the smallest). 


4.2. Hierarchical Queries. A hierarchical or recursive query in SQL is a special 
type of query used to handle hierarchical structured data. A common example 
is a company database, which stores all employees data as well as the ID of the 
direct supervisor. Thus, reconstructing the leadership structure requires additional 
capabilities that enable recursion. The Lis. shows an alternative, not standard¬ 
ized, syntax for recursive queries that we implement in SelectScript. It adopts 
the START WITH ... CONNECT BY construct that was originally introduced by Ora¬ 
cle m- The SQL standard [18] defines a syntax that involves the keywords WITH 
RECURSIVE and requires to associate query expressions with a name, which allows 
to reuse them. However, since we are not dealing with tables of finite length but 
rather with functions that might generate endless results, we had to integrate an 
additional STOP WITH construct, used to define abort conditions. The START WITH 
expressions are used, as the name suggests, to define local variables that might be 
required and to define initial conditions. 

Listing 2. Generic syntax to support hierarchical queries in Se- 
legtSgript. 

1 SELECT ... FROM ... WHERE 

2 

3 START WITH value # start expressions 

4 CONNECT BY (NO CYCLE | UNIQUE | MEMORIZE int | MAXIMUM int) 

5 value = func(value# recursion 

6 STOP WITH value > ... or value ... # stop conditions 


All of the work is actually done with the help of the central CONNECT BY expres¬ 
sions. It is used to denote which values within the search are affected and how 
they are changed from iteration to iteration, in this case using a previously defined 
function. The elements listed above, namely SELECT, FROM, WHERE, START WITH, 
CONNECT BY, and STOP WITH, are sufficient to describe the entire search problem 
but, as previously mentioned, we also want to include the possibility to explore dif¬ 
ferent search strategies. The design space exploration can be manually performed 
using the accompanying keywords in the CONNECT BY expression. Each of them 
tweaks the current, or applies another, search strategy. The method that is applied 
at default is a depth-first search algorithm, which in contrast to the table provided 
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in Fig. would generate more results by allowing cycles (cf. Lis. |^. In some sit¬ 
uations cycles within the search result might be desired, but to prevent them and 
therefore to reduce the search space, the NO CYCLE keyword has to be added to the 
query (cf. Lis.[^. The application of the keyword UNIQUE further reduces the space 
of possible paths, by allowing a node within the graph to be traversed only once (cf. 
Lis. [^. The application of MEMORIZE automatically generates a connected graph 
at first, similar to the one in Fig. which is afterwards traversed with a bidirec¬ 
tional^ search algorithm. This reduces the search space by half trading memory 
consumption and prevents multiple visits of a node, but it requires an additional 
stop parameter that determines the maximal length of the resulting paths. This 
maximal path length is defined by the associated integer value (cf. Lis. [^. The 
algorithm has a further advantage, it generates all simple paths, namely a path 
with no repeated nodes, ordered by their length, starting with the shortest path. 
Finally, the keyword MAXIMUM was introduced to denote the maximum number of 
results that is returned, for example 1000 possible paths for a mobile robot might 
be a sufficient result (cf. Lis.|^. 


5. Appications 


The following two sub-sections are used to demonstrate the applicability of our 
approach to solve reasoning problems. Therefore we choose the two examples that 
were already depicted in the teaser figure on the first page. These are problems 
that are commonly not solved by applying an SQL-like syntax, but as we will 
demonstrate it offers a convenient way. The Tower of Hanoi Sec. |5.1| is used to 
present the previously introduced new parts of our language step by step, while 
Sec. |5.2| is used as a proof of concept that demonstrates the language is applicable 
to solve robotic problems in a complex 3D environment. 


5.1. Tower of Hanoi. To present all steps that are required to solve the Towers 
of Hanoi problem, we start with the basic Python functionality that is required. 
The code snippet in Lis. is therefore used to load the basic interpreter module 
(line 1). If needed, a SelectScript user is required to implement additional 
functions within the host programming language, as it is done at line 3 with the 
move function. This function is used to execute valid steps, it therefore takes as 
input the configuration of the towers (a list of lists) and a step to be performed 
[from, to]. The following examples are used to solve the Tower of Hanoi problem 
for three disks, which requires at least seven steps. The minimal number of steps 
can be calculated with the formula — 1. The list [[3, 2, !],[],[]] thus denotes 
the initial configuration, where the three towers are represented by three lists and 
the first tower has the three ordered disks, namely 3 large disk, 2 medium disk, and 
1 small disk, while [[],[], [3, 2, 1]] defines the final configuration. The result of the 
move function is either a new configuration of towers or an empty list in case of an 
invalid step. This function is made accessible from within SelectScript in line 
12. All of the following SelectScript listings that present different solutions to 
the problem have to be presented as strings, see therefore line 14, before they are 
compiled at runtime (line 16) and evaluated (line 17). 


^For more information, see our benchmark at: www.aizac. info/bi-graph-search-benchmark 
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Listing 3. Basic Python program stub, including all required in¬ 
structions for the Tower of Hanoi application. 

1 import SelectScript, SelectScript.Interpreter 

2 

3 def move(step, towers): 

4 if not towers or not towers [step [0]] : pass 

5 elif not towers [step [1]] or towers[step [1]] [-1] >towers[step [0]] [-1] : 

6 #append element on top from another tower top 

7 towers[step[l]].append(towers[step[0]].pop()) 

8 return towers 

9 return [] 

10 

11 ss = SelectScript.Interpreter() 

12 ss . addFunction(’ move’ , move) 

13 

14 problem = """ insert SelectScript here """ 

15 

16 ir = SelectScript.compile(problem) 

17 result = ss.eval(ir) 


The example in Lis. [^presents a vanilla approach, whereby recursion is applied 
with the nesting of seven move functions. That means, that this script actually iter¬ 
ates through all possible configurations, which results in a relatively long evaluation 
time of more than 10 seconds. We report in the listing captions the evaluation time 
of the scripts, so that the performance of different approaches can be compared. A 
Intel Core i5-4200U (1.6 GHz 3 MB) machine with 8 GB of RAM is used. The code 
is running on one core of the machine sequentially. The sequence of resulting steps 
is printed in the comment in line 12. As introduced in Sec.[^ the this keyword is 
used as a pointer to specify where to place the elements from the FROM expression, 
if multiple elements are declared, then the name.this notation is applied to refer 
to those elements. 

Listing 4. Vanilla approach that uses nested move functions to 
iterate over all possible configurations. (Runtime: 10.09 sec) 

moves = [[0,1], [0,2], [1,0], [1,2], [2,0], [2,1]]; 

SELECT ml.this, m2.this, m3.this, m4.this, mb.this, m6.this, mT.this 
FROM ml=moves , m2 = moves , m3 = moves , m4 = moves , m5 = moves , m6 = moves , m7 = moves 
WHERE [[],[], [3,2,1] ] == move (m7 . this , 

move(m6.this , 
move(m5.this, 
move(m4.this , 
move(m3.this , 
move(m2.this , 

move (ml . this , [ [3,2,1] , [] , [] ] ))))))) 

AS list ; 

# result: [ [0,2] , [0,1] , [2,1] , [0,2] , [1,0] , [1,2] , [0,2] ] 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 


The application of the newly integrated constructs simplifies the code dramat¬ 
ically and also speeds up the execution. The WHERE expression is still applied to 
identify the target configuration, whereby new towers are continuously produced 
by the CONNECT BY expression, as in Lis. The start configuration is defined in 
line 4 and the generation of new intermediate steps ends if either an invalid step 
was applied or the depth of the search exceeds the level of seven. In this way it 
is also possible to generate longer results than seven steps, simply by adapting the 
stop condition. The evaluation result of the query will then be a list that contains 
all possible solutions, namely valid sequences with cycles. 
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Listing 5. Application of the basic hierarchical query. (0.89 sec) 

2 SELECT this FROM moves WHERE [[] , [] » [3,2,1]] == move(this, tower) 

3 

4 START WITH tower = [ [3,2,1] , [] , [] ] , level=l 

5 CONNECT BY tower = move(this, tower), level=level+1 

6 STOP WITH level==7 or []==move(this, tower); 

The search can be tweaked by additional parameters, as for example in the script 
Lis. Since the SELECT expression is used to generate the intermediate steps, we 
have to add additional elements, such as the current tower configuration or the level. 
Otherwise, no valid results could be generated from the applicable steps only. In 
the result shown in the last line in Lis. multiple steps have to be repeated in 
order to reach the target configuration. Nevertheless, both optimization strategies 
perform better than the previous script. 

Listing 6. Application of two additional keywords that result in a 
reduction of the search space. (NO CYCLE=0.32sec, UNIQUE=0.19sec) 

2 SELECT this, tower FROM moves WHERE [ [] , [] , [3,2,1]] == move(this , tower) 

3 

4 START WITH tower = [ [3,2,1] , [] , [] ] , level = 1 

5 CONNECT BY NO CYCLE # or UNIQUE 

6 tower = move(this, tower), level = level+1 

7 STOP WITH level == 7 or [] == move(mov.this, tower); 

Lis. [^demonstrates the application of the bidirectional graph search method, it 
translates the entire query into an equivalent graph that gets analyzed afterwards. 
This might reduce evaluation time, but only for larger problems and by sacrificing 
memory. Since the additional parameter already defines the maximum resulting 
path length, it makes the application of an additional level variable, to control 
the length, unnecessary. Note that the problem below now contains four disks, 
which require at least 15 steps. 

Listing 7. Application of a bidirectional graph search algorithm. 

(0.17 sec) 

2 SELECT this, tower FROM moves WHERE [ [] , [] , [4,3,2,1]] == move(this, tower) 

3 

4 START WITH tower = [ [4,3,2,1] , [] , [] ] 

5 CONNECT BY MEMORIZE 15 

6 tower = move(this, tower) 

7 STOP WITH [] == move(this, tower); 


5.2. Robot Navigation. The following example is used to demonstrate that Se- 
legtSgript can also be applied to more complex environments when using the 
improvement described by our work. The teaser figure on the first page shows a 
screenshot of the path planning task for a mobile YouBot within a complex in¬ 
dustrial environment, which can be solved with the script in Lis. [^ A screencasfj^ 
showing the running evaluation was also uploaded to our YouTube-Channel. 

The depicted program structure pretty much reflects the previous examples. 
The first three lines are used to define relevant parameters, such as the ID of the 
robot, its target position, and the directions the robot is allowed to move (at each 
step). The applied functions move, position, distance, and checkCollision were 
defined externally. The move function here really moves the virtual robot in the 

®Demo: http://www.youtube.com/watch?v=EFRVOJSdKSM 
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virtual environment and checkCollision is used to identify (as its name suggests) 
if the object that is passed as a parameter is colliding with something within the 
environment or not. 

Thus, the only things that might look a bit unfamiliar in this example are the 
more complex stop conditions. Within the stop expression the short-cuts of a 
collision detection and some background knowledge according to the application of 
the distance function are applied. Thus, paths are cut off from a further search, 
if the distance from the current position to the target position cannot be reached 
anymore with the remaining number of steps. The IlQ-condition is an additional 
(experimental) language feature, which is applied at this case to give an acoustic 
feedback, only if a collision has occurred (listen to the video®). 

The result of the path search is depicted in Fig. it shows an external view on 
the situation that was presented at the main page. Although not directly visible, 
the red lines actually represent the 1000 possible paths that were identified by the 
algorithm. It has to be note, that the combinatorial amount of possible paths that 
require less than 20 steps exceeds 10^ (we tried it). As mentioned, the applied graph 
traversing algorithm identifies possible paths according to their length, starting with 
the shortest ones. 

Listing 8. Robotic path search in OpenRAVE^. 

1 robot = "YouBot"; 

2 start_pos = posit ion(robot) ; 

3 target_pos = [10.0, 9.0]; 

4 

5 directions = [[0, 1] , [0 , -1] , [1 , -1] , [ -1 , -1] , [1 , 0] , [-1 , 0] , [-1 , 1] , [1 , 1]]; 

6 

7 SELECT (this + cur_pos) FROM directions 

8 WHERE target_pos == move(robot, this + cur_pos) 

9 

10 START WITH cur_pos = start_pos, level = 1 

11 CONNECT BY MEMORIZE 20 MAXIMUM 1000 

12 cur_pos = move(robot, cur_pos + this), 

13 level = level+1 

14 STOP WITH target_pos == move(robot, this+cur_pos) OR 

15 distance(target_pos , this + cur_pos) > 0.5 ♦ (20-level) OR 

16 IF(checkCollision(robot) ; 

17 piaySound( "/usr/share/sounds/ubuntu/stereo/bell.ogg" ) , 

18 True) # ; else is not required here ... 

19 AS list; 


6. Summary & Outlook 

We have introduced SelegtSgript, a new declarative embedded domain-specific 
language (DSL), and shown that it can run as an intermediate layer on top of differ¬ 
ent discrete simulation environments and world models hiding the discrepancies of 
different APIs. In addition, we have demonstrated that accessing information with 


Rt is an expression, that can be used for logging or even to adapt the query, and which can be 
placed everywhere. The last expression in the then or else block thereby defines the return value. 
Thus, the previous result of checkCollision can also be changed to False (cf. line 18 in Lis.[^. 
IF( condition ; 

then, execute, a, sequence, of, expression ; 
else, another, sequence, of, expressions ) 
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Figure 6. Screenshot^ of OpenRAVE including the entire envi¬ 
ronment, the building is depicted in blue and internal objects/ob¬ 
stacles are green, the yellow lines mark the procedure (visited po¬ 
sition) of the algorithm, red lines mark the resulting paths. 


an SQL-like syntax provides a more “natural” and elegant mean than extracting 
the same information the old fashioned way, i. e. looping through the API. 

The focus of this work lays on the extension of the DSL to better support rea¬ 
soning and to hide the complexity of applying different strategies and methods. 
Using hierarchical queries the language can be applied stand alone to solve classical 
problems, such as the Towers of Hanoi, but also to solve problems in complex 3D 
environments, whereby constraints are defined by the configuration of the applied 
model, e. g. walls, obstacles, the geometry and configuration of the robots, etc. 

SelectScript is currently at an early stage, we are exploring different methods, 
constructs, and ideas, such as including additional search methods by applying 
heuristics or integrating probabilistic aspects to be able to query for the most 
likely results. Early development also shows that it is possible to automatically 
parallelize the result generation. Although relatively small, our currently developed 
interpreter in pure Python is relatively slow. Thus, our main focus lays in the port 
of the language to C and in devising a more efficient implementation. By doing 
so, we hope that it will be easier to make SelegtSgript applicable to other host 
programming languages. 

SelegtSgript is part of a larger research effort, whereby we try to make all 
information origination from an ecology of smart systems accessible and queryable. 
In [19] and [20] we had described a methodology that overlays smart and distributed 
environments with some kind of distributed scene graph (by using cloud based tech¬ 
niques). This enables us to organize and access these environments in a way that 
world models (for a certain area) on the basis of OpenRAVE can be reconstructed. 
The next step in our research will cover the area of reasoning on functions. If you 
look at the Robot Operating System (ROS), it offers a way to access a multitude 
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of transformation, filter, aggregation, fusion, interpretation functionality. But how 
do we use it? Imperatively! Cynically it can be said that we are still programming 
assembly, but on far more complex machines. Why not “simply” solving this in a 
declarative way. Reasoning about the sequential application of “functions” for data 
transformation is probably quite similar to the identification of action sequences. 
We know what systems are available (their configuration/pose, data formats, etc.) 
[start configuration], we have this huge amount of ROS functionality (with known 
input and output formats) [rules] and we know what kind of information/represen¬ 
tation we want to have (as well as a semantic to describe it) [goal]. 
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